Ems decision support interface, event history, and related tools

ABSTRACT

Embodiments of the present invention include systems and methods for display and navigation of a clinical decision support process with portions thereof on separate display screens, as well as systems and methods for dynamically changing visual characteristics of softkeys on a patient monitor/defibrillator user interface screen based on clinical decision support or differential diagnosis processes, as well as a code review interface configured to permit a user to see what was displayed on a patient monitor/defibrillator user interface screen at any time during a medical event, as well as to see snapshots of other recorded parameters over the course of the medical event for purposes of code review, patient transfer, and improved patient care.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit under 35U.S.C. §120 of U.S. patent application Ser. No. 14/151,602, filed onJan. 9, 2014, entitled “EMS DECISION SUPPORT INTERFACE, EVENT HISTORY,AND RELATED TOOLS,” which claims priority to and the benefit of U.S.Provisional Patent Application Ser. No. 61/751,743, filed on Jan. 11,2013, and of U.S. Provisional Patent Application Ser. No. 61/818,334,filed on May 1, 2013, all of which are incorporated herein by referencein their entireties for all purposes.

TECHNICAL FIELD

Embodiments of the present invention relate generally to tools forfacilitating acute care treatment, and more specifically to systems andmethods for clinical decision support and differential diagnosis.

BACKGROUND

In the pre-hospital and acute care treatment setting, medical respondersoften have difficulties in accurately determining the proper diagnosisof a particular patient. Even well-trained physicians often havedifficulty under emergency conditions in which split second decisionsare required with limited information. Computer-automated diagnosis wasdeveloped to improve the accuracy, effectiveness, and reliability ofboth field and hospital patient treatment.

Automated differential diagnosis utilizes computer inference algorithmssuch as Bayesian algorithms, neural networks, or genetic algorithms.According to a Wikipedia posting:

-   -   The Bayesian network is a knowledge-based graphical        representation that shows a set of variables and their        probabilistic relationships between diseases and symptoms. They        are based on conditional probabilities, the probability of an        event given the occurrence of another event, such as the        interpretation of diagnostic tests. Bayes' rule helps us compute        the probability of an event with the help of some more readily        information and it consistently processes options as new        evidence is presented. In the context of CDSS [(clinical        decision support system)], the Bayesian network can be used to        compute the probabilities of the presence of the possible        diseases given their symptoms. Some of the advantages of        Bayesian Network include the knowledge and conclusions of        experts in the form of probabilities, assistance in decision        making as new information is available and are based on unbiased        probabilities that are applicable to many models. Some of the        disadvantages of Bayesian Network include the difficulty to get        the probability knowledge for possible diagnosis and not being        practical for large complex systems given multiple symptoms. The        Bayesian calculations on multiple simultaneous symptoms could be        overwhelming for users. Example of a Bayesian network in the        CDSS context is the Iliad system which makes use of Bayesian        reasoning to calculate posterior probabilities of possible        diagnoses depending on the symptoms provided. The system now        covers about 1500 diagnoses based on thousands of findings.        Another example is the DXplain system that uses a modified form        of the Bayesian logic. This CDSS produces a list of ranked        diagnoses associated with the symptoms.    -   Artificial Neural Networks (ANN) is a nonknowledge-based        adaptive CDSS that uses a form of artificial intelligence, also        known as machine learning, that allows the systems to learn from        past experiences/examples and recognizes patterns in clinical        information. It consists of nodes called neurodes and weighted        connections that transmit signals between the neurodes in a        unidirectional fashion. An ANN consists of 3 main layers: Input        (data receiver or findings), Output (communicates results or        possible diseases) and Hidden (processes data). The system        becomes more efficient with known results for large amounts of        data. The advantages of ANN include the elimination of needing        to program the systems and providing input from experts. The ANN        CDSS can process incomplete data by making educated guesses        about missing data and improves with every use due to its        adaptive system learning. Additionally, ANN systems do not        require large databases to store outcome data with its        associated probabilities. Some of the disadvantages are that the        training process may be time consuming leading users to not make        use of the systems effectively. The ANN systems derive their own        formulas for weighting and combining data based on the        statistical recognition patterns over time which may be        difficult to interpret and doubt the system's reliability.        Examples include the diagnosis of appendicitis, back pain,        myocardial infarction, psychiatric emergencies and skin        disorders. The ANN's diagnostic predictions of pulmonary        embolisms were in some cases even better than physician's        predictions. Additionally, ANN based applications have been        useful in the analysis of ECG (a.k.a. EKG) waveforms.    -   A Genetic Algorithm (GA) is a nonknowledge-based method        developed in the 1940s at the Massachusetts Institute of        Technology based on Darwin's evolutionary theories that dealt        with the survival of the fittest. These algorithms rearrange to        form different re-combinations that are better than the previous        solutions. Similar to neural networks, the genetic algorithms        derive their information from patient data. An advantage of        genetic algorithms is these systems go through an iterative        process to produce an optimal solution. The fitness function        determines the good solutions and the solutions that can be        eliminated. A disadvantage is the lack of transparency in the        reasoning involved for the decision support systems making it        undesirable for physicians. The main challenge in using genetic        algorithms is in defining the fitness criteria. In order to use        a genetic algorithm, there must be many components such as        multiple drugs, symptoms, treatment therapy and so on available        in order to solve a problem. Genetic algorithms have proved to        be useful in the diagnosis of female urinary incontinence.

Despite the fact that automated differential diagnosis systems have beendeveloped and attempted to be implemented for more than 35 years now,they have not achieved any acceptance in the emergency medical settingfor acute care treatment (ACT). In large part, this failure is due tothe conditions under which emergency care of acute conditions arepracticed. In those situations, such as the treatment of trauma, cardiacarrest or respiratory arrest, speed of decision-making is critical andcaregivers already must split their time and attention between thepatient and the physiological monitors and defibrillators. In suchsituations, automated differential diagnosis (ADD) tools are oftenviewed as interfering with the caregiving process and as a delay totreatment of the patient. Given that every minute can result in a 10%drop in survival rate, such as is the case for cardiac arrest, it is notsurprising that ADD tools are ignored by the very people that they weredesigned to assist.

It has also been found that much of the patient's medical history isinaccessible by the caregiver at the time of the acute medical conditionbecause patients are often treated in the prehospital setting wherefamily members are often not present at the time of the injury.

SUMMARY

Embodiments of the present invention include a system that provides atool for the caregiver to more efficiently and accurately perform adifferential diagnosis that is integrated into the caregivers existingworkflow during emergency situations. Embodiments of the presentinvention may also provide an integrated view of physiological data fromthe patient, along with therapeutic treatment and patient history andexamination findings, in an automated way to caregivers.

In Example 1, a method for code review of a medical event according toembodiments of the present invention includes displaying, on a firstdevice screen, a user interface during the medical event; recordingimages of the user interface, each of the images representing anentirety of the user interface associated with a time during the medicalevent, wherein the images are recorded at least once every second;displaying, on a second device screen, a visual timeline indicator and auser interface replicator, the user interface replicator displaying theimages of the user interface and the visual timeline indicatorrepresenting a time associated with each of the images, wherein thevisual timeline indicator and the user interface replicator permitsequential playback and review of the user interface images from themedical event, and wherein the visual timeline indicator accepts userinput to move the sequential playback to a different time associatedwith the medical event.

In Example 2, the method of Example 1, wherein the visual timelineindicator includes a timeline including a beginning time of the medicalevent and an end time of the medical event, the method furthercomprising indicating on the timeline the time associated with the imageof the user interface shown in the user interface replicator.

In Example 3, the method of any of Examples 1-2, wherein the indicatingon the timeline comprises using an indicator on the timeline to indicatethe time associated with the image of the user interface shown in theuser interface replicator.

In Example 4, the method of any of Example 1-3, further comprisingadvancing the indicator along the timeline in a direction from thebeginning time toward the end time during sequential playback of theuser interface images.

In example 5, the method of any of Examples 1-4, wherein the visualtimeline indicator accepts user input by permitting scrolling of theindicator to a different position along the timeline.

In Example 6, the method of any of Examples 1-5, wherein the visualtimeline indicator displays the time associated with each of the imagesin an hour-minute-second format.

In Example 7, the method of any of Examples 1-6, wherein the visualtimeline indicator includes one or more event markers marking occurrenceof clinically-relevant sub-events during the medical event.

In Example 8, the method of any of Examples 1-7, wherein the one or moreevent markers include a drug event marker indicating a time at which adrug was administered to a patient during the medical event.

In Example 9, the method of any of Examples 1-8, wherein the one or moreevent markers include a defibrillation event marker indicating a time atwhich a defibrillation shock was applied to a patient during the medicalevent.

In Example 10, the method of any of Examples 1-9, wherein the one ormore event markers include an ROSC event marker indicating a time atwhich a patient returned to spontaneous circulation.

In Example 11, the method of any of Examples 1-10, wherein the one ormore event markers include a rearrest event marker indicating a time atwhich a patient returned to cardiac arrest.

In Example 12, the method of any of Examples 1-11, wherein the one ormore event markers include an alarm event marker indicating a time atwhich an alarm was activated.

In Example 13, the method of any of Examples 1-12, further comprisingdisplaying a cursor on the second device screen and, when the cursor ishovered over or near a time represented by the visual timelineindicator, displaying on the second screen at or near the cursor theimage of the user interface associated with the time.

In Example 14, the method of any of Examples 1-13, further comprising,when the cursor is hovered over or near the time, displaying at or nearthe cursor a textual representation of the time.

In Example 15, a method for decision support during a medical eventaccording to embodiments of the present invention includes displaying,on a screen on a device, a user interface during the medical event,wherein the user interface comprises two or more softkeys eachrepresenting a possible user selection; collecting physiological datafrom a patient with the device; determining, based on the physiologicaldata, which one of the two or more softkeys represents the possible userselection that most closely conforms to a treatment or diagnosisprotocol; and based on the determination, visually distinguishing theone of the two or more softkeys from the others of the two or moresoftkeys on the user interface.

In Example 16, the method of Example 15, wherein visually distinguishingthe one of the two or more softkeys comprises making the one of the twoor more softkeys larger than the others of the two or more softkeys.

In Example 17, the method of any of Examples 15-16, wherein visuallydistinguishing the one of the two or more softkeys comprises changing aposition of the one of the two or more softkeys on the user interface.

In Example 18, the method of any of Examples 15-17, wherein visuallydistinguishing the one of the two or more softkeys comprises changing acolor of the one of the two or more softkeys on the user interface.

In Example 19, the method of any of Examples 15-18, wherein visuallydistinguishing the one of the two or more softkeys comprises changing aborder of the one of the two or more softkeys on the user interface.

In Example 20, the method of any of Examples 15-19, wherein visuallydistinguishing the one of the two or more softkeys comprises making theone of the two or more softkeys dynamically flash on the user interface.

In Example 21, the method of any of Examples 15-20, wherein visuallydistinguishing the one of the two or more softkeys comprises displayingon the screen a legend describing why the one of the two or moresoftkeys has been visually distinguished.

In Example 22, the method of any of Examples 15-21, wherein the one ofthe two or more softkeys is a cardiac distress softkey, and wherein thelegend textually indicates a possible cardiac arrhythmia.

In Example 23, a method for decision support during a medical eventaccording to embodiments of the present invention includes displaying,on a first screen on a first device, a user interface during the medicalevent, wherein the user interface comprises two or more softkeys eachrepresenting a possible user selection; collecting physiological datafrom a patient with the first device; displaying, on a second screen ona second device, a visual representation of a clinical decision supporttree and an indication of a current node on the clinical decisionsupport tree, wherein the two or more softkeys each represent thepossible user selection from the current node on the clinical decisionsupport tree.

In Example 24, the method of Example 23, wherein the visualrepresentation of the clinical decision support tree includes, inaddition to the current node, at least one prior node and at least onesubsequent node.

In Example 25, the method of any of Examples 23-24, wherein selection ofone of the two or more softkeys advances the indication of the currentnode on the second screen to a subsequent node as selected by the one ofthe two or more softkeys.

In Example 26, the method of any of Examples 23-25, wherein the secondscreen permits scrolling and resizing of the visual representation ofthe clinical decision support tree.

In Example 27, the method of any of Example 23-26, wherein the visualrepresentation of the clinical decision support tree is centered at thecurrent node on the second screen.

In Example 28, the method of any of Examples 23-27, wherein the visualrepresentation of the clinical decision support tree is positioned onthe second screen based on the current node.

In Example 29, the method of any of Examples 23-28, wherein the visualrepresentation of the clinical decision support tree on the secondscreen is positioned based on the current node, and wherein theselection of the one of the two or more softkeys repositions the visualrepresentation of the clinical decision support tree on the secondscreen based on the subsequent node.

In Example 30, the method of any of Examples 23-29, wherein the visualrepresentation of the clinical decision support tree on the secondscreen is centered at the current node, and wherein the selection of theone of the two or more softkeys recenters the visual representation ofthe clinical decision support tree on the second screen at thesubsequent node.

In Example 31, a method for decision support during a medical eventaccording to embodiments of the present invention includes: during themedical event, collecting physiological data from a patient at a firstfrequency with a patient monitoring device; guiding a user through aclinical decision support process with a display screen during themedical event; determining, with the clinical decision support process,a status of a patient; and based on the status of the patient, selectinga second frequency at which to collect the physiological data from thepatient.

In Example 32, the method of Example 31, further comprising collectingthe physiological data from the patient at the second frequency.

In Example 33, the method of any of Examples 31-32, wherein the statusof the patient indicates traumatic brain injury, and wherein the secondfrequency is selected to be greater than the first frequency.

In Example 34, the method of any of Examples 31-33, wherein the secondfrequency is at least once every five minutes.

In Example 35, a system for code review of a medical event according toembodiments of the present invention includes a first screen configuredto visually display a clinical decision support tree used in the medicalevent; a second screen configured to visually display a replication of auser interface of a patient monitoring device as the user interfaceappeared at times during the medical event, wherein selecting a locationwithin the clinical decision support tree on the first screen causes thesecond screen to display the replication of the user interfacecorresponding to a time during the medical event represented by thelocation within the clinical decision support tree.

In Example 36, the system of Example 35, wherein the second screen ispart of the patient monitoring device.

In Example 37, the system of any of Examples 35-36, wherein the firstscreen is further configured to visually indicate on the clinicaldecision support tree a user's advancement through the clinical decisionsupport tree in synchronization with advancement of the replication ofthe user interface on the second screen.

In Example 38, a method for decision support according to an embodimentof the present invention includes displaying, on a screen, a userinterface during the medical event, wherein the user interface comprisestrending information for a patient condition; collecting physiologicaldata from a patient with a device; providing clinical decision supportusing at least some of the physiological data and at least some userinput data; establishing a range for the patient condition based on theclinical decision support; and visually indicating on the user interfacewhether all or portions of the trending information is within the range.

In Example 39, the method of Example 38, wherein the screen is on thedevice.

In Example 40, the method of any of Examples 38-39, wherein visuallyindicating on the user interface whether all or portions of the trendinginformation is within the range further comprises displaying portions ofthe trending information that falls outside of the range in a firstcolor, and displaying portions of the trending information that fallswithin the range in a second color different from the first color.

In Example 41, the method of any of Examples 38-40, wherein the range isa first range, the method further comprising establishing a second rangefor the patient condition based on the clinical decision support, andvisually indicating on the user interface whether all or portions of thetrending information is within in the second range.

In Example 42, the method of any of Examples 38-41, further comprisingestablishing a third range for the patient condition based on theclinical decision support, wherein the first, second, and third rangesdo not overlap each other, and visually indicating on the user interfacewhether all or portions of the trending information is within the thirdrange.

In Examples 43, the method of any of Examples 38-42, further comprisingcoloring portions of the trending information within the first range afirst color, coloring portions of the trending information within thesecond range a second color, and coloring portions of the trendinginformation within the third range a third color.

In Example 44, the method of any of Examples 38-43, wherein the firstcolor is green, wherein the second color is yellow, and wherein thethird color is red.

In Example 45, the method of any of Examples 38-44, wherein establishingthe range for the patient condition based on the clinical decisionsupport comprises establishing the range for the patient condition basedon the patient's age, wherein the patient's age is acquired via theclinical decision support.

In Example 46, a method for decision support according to an embodimentof the present invention includes displaying, on a screen, a userinterface during the medical event, wherein the user interface comprisesdosing information display for a drug; collecting physiological datafrom a patient with a device; providing clinical decision support usingat least some of the physiological data and at least some user inputdata; establishing a dosage recommendation for the drug based on theclinical decision support; and visually indicating the dosagerecommendation on the dosing information display of the user interface.

In Example 47, the method Example 46, wherein the screen is on thedevice.

In Example 48, the method of any of Examples 46-47, wherein establishingthe dosage recommendation based on the clinical decision supportcomprises establishing the dosage recommendation based on the patient'sage, wherein the patient's age is acquired via the clinical decisionsupport.

In Example 49, the method of any of Examples 46-48, wherein establishingthe dosage recommendation based on the clinical decision supportcomprises establishing the dosage recommendation based on the patient'sweight, wherein the patient's weight is acquired via the clinicaldecision support.

In Example 50, the method of any of Examples 46-49, wherein establishingthe dosage recommendation based on the clinical decision supportcomprises establishing the dosage recommendation based on the patient'sallergies, wherein the patient's allergies are acquired via the clinicaldecision support.

While multiple embodiments are disclosed, still other embodiments of thepresent invention will become apparent to those skilled in the art fromthe following detailed description, which shows and describesillustrative embodiments of the invention. Accordingly, the drawings anddetailed description are to be regarded as illustrative in nature andnot restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a clinical decision support system, according toembodiments of the present invention.

FIG. 2 illustrates a user interface for a medical device, according toembodiments of the present invention.

FIG. 3 illustrates the user interface of FIG. 2 upon selection of anacute care diagnosis mode, according to embodiments of the presentinvention.

FIG. 4 illustrates the user interface of FIGS. 2 and 3 upon selection ofa respiratory distress mode, according to embodiments of the presentinvention.

FIG. 5 is a table describing a differential diagnosis outline for acutedyspnea in adults.

FIG. 6 is a table describing clues to the diagnosis of dyspnea.

FIG. 7 is a table listing physical examination findings in the diagnosisof acute dyspnea.

FIG. 8A is a top portion of a common medical protocol and differentialdiagnosis flow chart for adult shortness of breath.

FIG. 8B is a continuation of the common medical protocol anddifferential diagnosis flow chart of FIG. 8A.

FIG. 9 illustrates a carbon dioxide snapshot waveform which may bedisplayed on the user interface when selected by the user, according toembodiments of the present invention.

FIG. 10 illustrates the carbon dioxide snapshot waveform of FIG. 9 withdisplayed measurements, according to embodiments of the presentinvention.

FIG. 11 illustrates a tablet computing device docked on a defibrillatordevice, according to embodiments of the present invention.

FIG. 12 illustrates a protocol for use in patients with cardiac arrest.

FIG. 13 illustrates an example trauma assessment protocol.

FIG. 14 illustrates an example rapid trauma assessment protocol.

FIG. 15 illustrates an example focused physical exam protocol.

FIG. 16 illustrates an example amputation injuries protocol.

FIG. 17 illustrates an example bleeding control protocol.

FIG. 18 illustrates an example burns protocol.

FIG. 19 illustrates an example electrocution protocol.

FIG. 20 illustrates an example spinal immobilization protocol.

FIG. 21 illustrates additional steps in the spinal immobilizationprotocol of FIG. 20.

FIG. 22 illustrates an example multi-system trauma protocol.

FIG. 23 illustrates an example near drowning protocol.

FIG. 24 illustrates an example trauma in pregnancy protocol.

FIG. 25 illustrates an example traumatic cardiac arrest protocol.

FIG. 26 illustrates a clinical decision support system, according toembodiments of the present invention.

FIG. 27 illustrates a computer system, according to embodiments of thepresent invention.

FIG. 28 illustrates a user interface display of a clinical decisionsupport tree, according to embodiments of the present invention.

FIG. 29 illustrates the user interface display of FIG. 28 with a portionof the clinical decision support tree resized, according to embodimentsof the present invention.

FIG. 30 illustrates the user interface display of FIGS. 28 and 29 withan additional portion of the clinical decision support tree resized,according to embodiments of the present invention.

FIG. 31 illustrates a user interface display with dynamic softkeys,according to embodiments of the present invention.

FIG. 32 illustrates the user interface display of FIG. 31 with onesoftkey emphasized based on clinical decision support, according toembodiments of the present invention.

FIG. 33 illustrates the user interface display of FIG. 31 with onesoftkey emphasized in a different way, based on clinical decisionsupport, according to embodiments of the present invention.

FIG. 34 illustrates a code review interface for reviewing user interfacedisplay data corresponding to a medical event, according to embodimentsof the present invention.

FIG. 35 illustrates a portion of a clinical decision support tree,according to embodiments of the present invention.

FIG. 36 illustrates a user interface display, according to embodimentsof the present invention.

While the invention is amenable to various modifications and alternativeforms, specific embodiments have been shown by way of example in thedrawings and are described in detail below. The intention, however, isnot to limit the invention to the particular embodiments described. Onthe contrary, the invention is intended to cover all modifications,equivalents, and alternatives falling within the scope of the inventionas defined by the appended claims.

DETAILED DESCRIPTION

FIG. 1 shows a block diagram of the system, according to embodiments ofthe present invention. In one embodiment, a combineddefibrillator/monitor device such as the E-Series manufactured by ZOLLMedical of Chelmsford Mass. has keys whose labeling is provided byon-screen text. The text is thus configurable in real time ether due toinput by the user or as a result of analysis and decision making by thedefibrillator or other devices with which the defibrillator is incommunication at the time of the defibrillator's use, such as thecomputer tablet device 214 or remote base station staffed by medicaldispatch or medical supervisory personnel in communication with thecomputer tablet. The computer tablet may take the form of an iPad (AppleCorp., Cupertino Calif.). Such screen-labeled keys may be referred to as“soft-keys”. A specific soft-key is initially labeled “Acute Carediagnose” at device turn-on as shown in FIG. 2, according to embodimentsof the present invention. Upon detecting a key press of the Acute CareDiagnose key, the defibrillator changes the functionality and labelingof the keys to those shown in FIG. 3. These five labels—“RespiratoryDistress” or alternatively “Dyspnea”, “Altered Mental Status”, “CardiacDistress”, “Trauma” and “Pain/Abnormal Nerve Sensation”—differ from thetraditional symptoms associated with differential diagnosis in that theyidentify classes of patients and potential workflows and diagnosis andtreatment pathways (DTP), and are listed in relative frequency withwhich paramedics and other emergency personnel encounter patientsmeeting these criteria in actual practice.

By pressing the soft-key for each DTP, the defibrillator is thenconfigured to potentially activate certain physiological sensors anddisplay the sensor data in such a way as to provide the caregiver theoptimal information, presented in the optimal fashion so as to diagnoseand treat the patient most accurately and efficiently. Each DTP mayinclude a template according to which sensor data, or the physiologicaland/or measurement data derived therefrom, is displayed in a way mostuseful and/or efficient for that particular DTP. For instance, if the“Respiratory Distress” soft-key is pressed, then the waveforms andnumeric physiologic data on the screen change to that shown in FIG. 4.Stored snapshots of individual CO2 breath waveforms may be initiated viathe CO2 Snapshot soft-key. These snapshots remain on the display forreference to the clinician both for automating measurements fordiagnosis as well as for assessing the effectiveness of a particulartherapy.

Heart sound measurement and detection may be incorporated into themonitoring device for the detection of S3 and S4 heart sounds andautomatically narrow the differential, or suggest for the rescuer toconfirm agreement with the software diagnosis, of heart failure orpulmonary edema. A flowchart for evaluating heart sounds is shown inFIGS. 8A and 8B. Pulse oximetry and capnography are also very helpfulmeasures and may be automatically incorporated into the algorithm formore accurate diagnosis. The same sensors used to detect heart soundsmay also be employed to detect breath sounds and to analyze theirquality. Specific algorithms may be employed to detect wheezing,crackles, rale or stridor, each of which may be indicative of aparticular disease.

Sensors such as flow sensors and O2 gas sensors are included in someembodiments, so that the additional physiological measurements such asvolumetric Co2, volumetric O2 and spirometry, which are relevant fordiagnosis and treatment of dyspnea, may be included and displayed on theRespiratory Distress DTP screen. An oxygen sensor may be located in thepatient's airway, which may assist in calculating the metabolic needs ofthe patient.

The display on the defibrillator 212 is a touchscreen, according to someembodiments of the present invention. The caregiver can easily initiatemeasurements such as on the CO2 snapshot waveform or the spirometrysnapshot waveform via touchscreen gesture such as a double tap. A zoomicon may exist in the upper corner of each waveform box, such as the CO2snapshot, such that when the zoom button is touched, that particularwaveform fills the display of the defibrillator. Another measurementbutton is present which, when touched, displays all the relevantmeasurements for a particular waveform, according to embodiments of thepresent invention. A gestural interface is provided as part of thetouchscreen. Using two fingers or finger and thumb to touch to twopoints in the waveform (which may also be referred to as a “caliper”measurement or gesture) will cause measurements to be displayed and/oroverlaid onto the physiological data, as illustrated in FIG. 10. Forinstance, dead space volume, phase II and III slopes which areindicative of COPD, and estimates of arterial pCO2 may be listed on thescreen after initiation of CO2 waveform measurement.

According to embodiments of the present invention, the processorcommunicably coupled with the touchscreen portion of a decision supportsystem may be configured to recognize the wave shape of a wave signalbeing displayed, and/or recognize the edge of an image being displayed,in order to improve the accuracy of a caliper touch gesture. Forexample, if a user were to use a caliper gesture to measure or “zoom in”on an ST elevation in an ECG wave display, the decision support systemmay be configured to recognize that if one of the user's fingers tapsjust below the top of the ECG wave, that the user likely intended toinclude the top of the ECG wave in the enlarged or selected view. Inaddition, the decision support system may be configured to permit anability to enlarge (zoom) and adjust measurement points individuallyusing the touchscreen. A tap/click and drag method may be used to setthe caliper gesture; for example, to hone in on a particular portion ofdisplayed waveform, the user may press on one point and drag to anotherpoint to indicate the endpoints of the caliper gesture.

Specific out-of-range readings can be displayed in red or highlighted byother mechanisms, such as bold-face font and/or flashing. Touching thehighlighted values will cause the display to show the possible diagnoseswhich are consistent with the measurements, according to embodiments ofthe present invention. A specific graphical zone of the screen can bedesignated with a graphical image of the computer tablet. By draggingwaveforms, measurements, or any other data object shown on the displayover onto the computer tablet icon, it can automatically be presented onthe computer tablet that is linked to the defibrillator.

Capnography is helpful in the assessment of asthma, where an increasedslope in the expiratory plateau provides a measure of bronchospasm. Theslope of the plateau phase (phase III) provides a measure of airwayobstruction. The adequacy of b-agonist bronchodilatory therapy for anasthma exacerbation may be monitored through observation of slope changeof phase III.

As referenced in U.S. Patent Application Publication No. 2011/0172550,published on Jul. 14, 2011, which is incorporated by reference herein inits entirety for all purposes, the data for the patient's history may beentered via the computer tablet with patient physiological measures viathe monitor. As the differential diagnosis often implicates both patienthistory, patient examination findings along with measures of thepatient's physiological state via such monitoring as ECG, capnographyand pulse oximetry, these data elements are integrated into a userinterface that automatically or semi-automatically integrates thevarious data elements on a single differential diagnosis screen withinthe application on the computer tablet. The interface may begin byasking the rescuer to choose from a list of common presenting symptomsor complaints by the patient, for example dyspnea or respiratorydistress. The information such as on the screens of FIGS. 5, 6, and 7(taken from Am Fam Physician 2003; 68:1803-10) provides one possiblestructured approach for rescuers to obtain information. As patienthistory and physical examination findings are entered on the computertablet, the differential diagnosis page will gradually narrow down thepossible diagnoses.

In another embodiment, the defibrillator contains a docking feature forpropping up a computer tablet such as an Apple® iPad® on top of thedefibrillator in a stable position via mounting features integrated ontothe defibrillator, as illustrated in FIG. 11. Other mobile computingdevices, including tablet computers, an iPhone®, an iTouch®, and othertouchscreen monitors may be used. Alternatively, a low power, batterypowered, touchscreen monitor may be used, such as, for example, thosethat transfer information to and from a computing device via a wired orwireless USB connection. Communication may be provided wirelesslybetween the two devices (the medical device and the mobile computingdevice, for example). Other communicable coupling may be achievedbetween the two devices; for example, wired. The iPad may include aprotective housing and/or waterproof housing to protect it from thetypical physical abuse it would likely encounter in the prehospitalenvironment. Mounting features integral to such an iPad housing allow itto be easily attached on top of the defibrillator on scene. The mountingfeature on the defibrillator may be able to hinge to allow the iPad® tohinge down when not in use into a protective pocket on thedefibrillator. The iPad® may also be undocked and used nearby to thedefibrillator, without need for physical connection. A physical slot mayalso be provided, preferably at the side, top or back of the unit thatallows for the iPad® to have its battery charged by the defibrillator.Internal to the frame of the iPad® protective housing is the standardiPad® connector, while on the exterior of the frame of the iPad®protective housing are much more robust mechanical and electricalconnections that can withstand the extensive abuse experienced bymedical devices in the prehospital emergency setting, according toembodiments of the present invention.

The results of this integrated analysis of physiological data, patienthistory and examination findings may then be displayed on thedefibrillator, potentially in the form of asking to make an additionalphysiological measurement. The results of this integrated analysis ofphysiological data, patient history and examination findings mayalternatively, or additionally, be displayed on the tablet computer.According to some embodiments of the present invention, the tabletcomputer, or other mobile computing device, may be communicably coupledwith the defibrillator or other physiological assessment device, forexample through a wireless connection. As used herein, the phrase“communicably coupled” is used in its broadest sense to refer to anycoupling whereby information may be passed. Thus, for example,communicably coupled includes electrically coupled by, for example, awire; optically coupled by, for example, an optical cable; and/orwirelessly coupled by, for example, a radio frequency or othertransmission media. “Communicably coupled” also includes, for example,indirect coupling, such as through a network, or direct coupling.

According to embodiments of the present invention, a user interfacedevice is communicably coupled to a processor, and the processor isconfigured to receive data entered via the user interface device, aswell as data received from one or more sensors, in order to performclinical decision support based on both data sources. The user interfacedevice may include one or more devices such as a touch screen computer,a tablet computer, a mobile computing device, a smart phone, an audioreceiver, an audio transmitter, a video receiver, a video transmitter, acamera, and a “heads up” display projected onto a user's glasses or faceshield. A small monitor may be mounted onto eyeglasses, a face shield,and/or integrated with other wearable communications devices, such as,for example, an ear bud or a Bluetooth® hands free phone adaptor. Theuser interface device may include a combination of devices for conveyingoptions and receiving input; for example, an audio speaker may be usedto convey possible DTPs, and an audio receiver may be used to receive averbal command indicating a selection of one of the DTPs. Instead of anaudio receiver, a video camera may be used to receive a gestural commandthat will be interpreted by the processor as a selection of one of thepossible DTPs, or input elements. Using hands-free devices for userinterface devices may free the hands of a caregiver to perform clinicaltasks, while still permitting non-intrusive decision support and/ordifferential diagnosis for the caregiver.

FIGS. 8A and 8B illustrate a differential diagnosis and/or clinicalsupport process through which a computer processor may take a caregiver,using the user interface device, according to embodiments of the presentinvention. For example, if the caregiver selected “Respiratory Distress”from among the five DTPs presented on the screen of FIG. 3, then theuser interface device would prompt the caregiver to input informationabout step 802 in the flowchart of FIG. 8, which flows from top tobottom. At step 802, if the 12-lead reveals an S3 heart sound, or if theDyspnea Engagement Score is greater than 3, then the decision supportsystem will take the user through the Acute Decompensated Heart Failure(CHF) decision/diagnosis process.

The decision support system may take into account both physiologicaldata received from sensors, and information data received from thecaregiver (e.g. via mobile computing device such as an iPad®), inhelping the caregiver move from one decision point in the flow chart tothe next, while updating any display or information provided along theway. For example, the decision support system may indicate to the userthat, based on processing of the ECG data, there does not appear to bean S3 heart sound present, and ask the caregiver to confirm thisassessment. The decision support system may also, or alternatively,request the caregiver to enter a Dyspnea Engagement Score, or suggestone for confirmation by the caregiver. At step 802, if the 12-leadreveals no S3 heart sound, or if the Dyspnea Engagement Score is lessthan 3, then the decision support system will recognize that thecaregiver is not dealing with a CHF situation, but then moves to step804 in which the decision support system changes its display and/orinput prompts in order to help the caregiver determine whether to enterthe Asthma treatment path or the COPD treatment path.

Again, the decision support system may factor in various physiologicaldata from sensors, as well as various informational data received aboutthe particular patient, in helping to support the caregiver's decision.For example, as illustrated in FIG. 6, if the patient information(either entered by the caregiver or obtained from another source)indicates that the patient is involved in heavy tobacco use, thedecision support system will recognize at step 804 that a COPD diagnosisis more likely, whereas if the caregiver indicates to the decisionsupport system that the patient is experiencing a cough, or has ahistory of asthma, the decision support system may recognize at step 804that an Asthma diagnosis is more likely. In addition to, oralternatively to, the informational diagnosis support reflected in FIG.6, the decision support system may gather findings using physiologicaldata to help the caregiver determine the appropriate treatment path. Forexample, if a breathing or breath sound sensor generates data that, whenprocessed, indicates clubbing, barrel chest, or decreased breath sounds,the decision support system may recognize at step 804 that a COPDtreatment path is more appropriate, whereas if the breath sound sensorgenerates data indicative of pulsus paradoxus, or if a muscle activitysensor indicates accessory muscle use, the decision support system mayrecognize at step 804 that an Asthma treatment path is more appropriate.

According to embodiments of the present invention, the decision supportsystem may suggest or propose a diagnosis or treatment path, for exampleby indicating statistical probabilities (based on charts and data suchas those of FIGS. 6 and 7) or relative likelihoods, and ask forconfirmation or final selection by the caregiver. For example if at step804 the decision support system receives confirmation of an Asthmadiagnosis, then the user interface device may change the informationpresented to the caregiver, for example by launching into a treatmentprotocol specific to the Asthma diagnosis. At step 806, the decisionsupport system may suggest that the caregiver attach a humidifier to thepatient's oxygen supply, and administer 2.5 milligrams of albuterolmixed with 0.5 milligrams of Atrovent administered by nebulizerconnected to a 6-9 liter per minute source, and may indicate that thedosage may be administered continuously as long as the heart rate is notgreater than 140. The decision support system may monitor the heartrate, and give a visual and/or audio indication when and if the heartrate reaches or approaches 140, in this example.

At step 808, the decision support system may help the caregiver decidewhether the patient is extremely bronchoconstricted, for example byshowing data or measurements related to blood oxygen content,respiration rate, or respiration volume. Upon a confirmation by thecaregiver that the patient is extremely bronchoconstricted at step 808,the decision support system may then suggest to the caregiver that a 125milligram dose of Solumedrol be administered over a slow (e.g. 2 minute)intravenous push. At step 810, the decision support system may help thecaregiver to decide whether the patient's symptoms have improved (e.g.whether the patient's shortness of breath has improved with thetreatment thus far). For example, the decision support system maydisplay and/or analyze the patient's end-tidal waveform, and suggestthat the patient does not appear to be responding to the treatment, andask for the caregiver's confirmation. If the caregiver confirms thedecision, then the decision support system may continue to guide thecaregiver through additional treatment options, for example thoseindicated in FIG. 8. In this way, the decision support system guides thecaregiver through complex decisionmaking processes, during the clinicalencounter, using both physiological data and informational data gatheredfrom the patient or input by the caregiver, in a way which would be tooinconvenient or time-consuming for the caregiver to perform absent thedecision support system.

The decision support according to embodiments of the present inventionmay or may not be fully automated. Inference engines utilizing Bayesiannetworks, neural networks, genetic algorithms, or simpler rule-basedsystems may be employed.

In another embodiment, the tissue CO2 or pH are measured by methods suchas those described in U.S. Pat. No. 6,055,447, which describes asublingual tissue CO2 sensor, or U.S. Pat. Nos. 5,813,403, 6,564,088,and 6,766,188, which describe a method and device for measuring tissuepH via near infrared spectroscopy (NIRS), and which are all incorporatedherein by reference in their entirety for all purposes. NIRS technologyallows the simultaneous measurement of tissue PO2, PCO2, and pH. Onedrawback of previous methods for the measurement of tissue pH is thatthe measurements provided excellent relative accuracy for a givenbaseline measurement performed in a series of measurements over thecourse of a resuscitation, but absolute accuracy was not as good, as aresult of patient-specific offsets such as skin pigment. One of thebenefits achieved by some embodiments of the present invention is theelimination of the need for absolute accuracy of these measurements, andthe reliance on only the offset and gain being stable over the course ofthe resuscitation. Tissue CO2 and pH are particularly helpful inmonitoring in the trauma DTP. Physiological parameters on display forthe trauma DTP may be one or more of: invasive and non-invasive bloodpressure, tissue CO2 and pH, ECG, SpO2 trending, and heart ratevariability risk index. The ECG may be analyzed to determine theinterval between adjacent R-waves of the QRS complexes and using thisinterval to calculate heart rate variability as a running differencebetween adjacent R-R intervals. It is known to those skilled in the artthat an abrupt reduction in variability will often precede by manyminutes a precipitous decline in a patient's blood pressure (traumaticarrest). By monitoring the trend in heart rate variability, thetraumatic arrest can be anticipated and prevented.

Another sensor of use for the trauma DTP is ultrasound, according toembodiments of the present invention. According to C. Hernandez et al.,C.A.U.S.E.: Cardiac arrest ultra-sound exam—A better approach tomanaging patients in primary non-arrhythmogenic cardiac arrest,Resuscitation (2007), doi:10.1016/j.resuscitation.2007.06.033, which hisincorporated by reference herein in its entirety for all purposes:

-   -   C.A.U.S.E. is a new approach developed by the authors. The        C.A.U.S.E. protocol addresses four leading causes of cardiac        arrest and achieves this by using two sonographic perspectives        of the thorax; a four-chamber view of the heart and pericardium        and anteromedial views of the lung and pleura at the level of        the second intercostal space at the midclavicular line        bilaterally. The four-chamber view of the heart and pericardium        is attained using either the subcostal, parasternal or apical        thoracic windows. This allows the individual performing the        examination to select the most adequate view depending on the        patients' anatomy. The authors recommend beginning with the        subcostal view first as this view makes it possible for the        practitioner to evaluate the heart without interrupting chest        compression. If this view is not possible then the apical or        parasternal approaches may be used during coordinated pulse        checks lead by the resuscitation team leader. A four-chamber        view is used in this protocol as it allows for ease of        comparison between the different chambers in the heart,        facilitating the diagnosis of hypovolemia, massive PE, and        cardiac tamponade (FIG. 6). Pneumothorax is diagnosed by        identifying the lack of sliding sign and comet-tail artifact        while looking in the sagittal plane at the second intercostal        space of the midclavicular line (FIG. 7). For both the cardiac        and lung views it is recommended to use a 2.5-5.0 phased array        transducer probe. This allows the examiner to use the same probe        for both lung, heart and if needed abdominal exam. This type of        probe was used by Knudtson in his study involving ultrasound for        the use of identifying pneumothorax as an addition to the FAST        exam, and it yielded very a high accuracy in detecting        pneumothorax, yet still remained useful in identifying the heart        and abdominal organs. The protocol is best described in diagram        form. [see FIG. 12]

The caregiver selecting elements of the flowchart results in theultrasound sensor being activated and images presented on the computertablet. Additional instructions can be requested from the interface oneither the computer tablet and/or the defibrillator. Based on theselections and instructions, the settings of the ultrasound can beadjusted to deliver the optimal images, according to embodiments of thepresent invention.

Although five diagnosis and treatment pathways are discussed withrespect to FIG. 3, the differential diagnosis/decision support systemmay be configured to support decisionmaking and diagnosis with respectto other DTPs, and may be configured to display and support variouscombinations of one or more DTPs, from among the five shown in FIG. 3and others. According to other embodiments of the present invention,each user may configure the decision support system to use customizedDTP for each DTP option; for example, the user may change the defaultseries of questions/steps/readings for the Trauma DTP with a new seriesof questions/steps/readings based on caregiver-specific,patient-specific, geography-specific, and/or regulation-specifictreatment protocols. In this way, the decision support system accordingto embodiments of the present invention operates to guide decisionmakingand diagnosis for a caregiver in a way that accommodates various kindsof DTPs.

For example, if a user selected the Trauma DTP option from the screen ofFIG. 3, the decision support system may be configured to guide a userthrough a decision and treatment pathway similar to that shown in FIGS.13-25. The user would then be presented with a series of furtheroptions, such as “amputation injury,” “bleeding control,” “burns,” andthe like. Selecting one of these further options would then cause thedecision support system to enter and display the particular pathway orpathways relevant to the selected option. According to embodiments ofthe present invention, the decision support system is comprised by auser interface device, independent of a medical device or one or moresensors, in a way which simply guides the caregiver through a series ofdecisions according to a pre-established flow chart. At a basic level, amedical device, such as a defibrillator, may include one or moredecision support flow charts and/or treatment protocols, which guide thecaregiver through various decisions, either with or without sensor dataor other data input. A graphical DTP may be included in a defibrillatordevice as a reference document, electronically navigable.

According to other embodiments, the decision support system is informedby a combination of caregiver observations, patient information, and/orsensor data. Assessment and/or scoring may be performed, either byreceiving data from the caregiver, or receiving data from sensors, orboth. For example, for a trauma DTP, the decision support system maytake into account pulse rate, breathing data, qualitative breathingdata, pulse rate, blood loss, blood pressure, presence of broken limbs,and/or compound fractures. Or, in a cardiac distress DTP, the decisionsupport system may be configured to display a cardiac arrest probabilityat a moment in time, which may be calculated and/or predicated by thedecision support system based on selected criteria. The decision supportsystem may also be configured to track certain criteria in order tosuggest treatment outcome probabilities, for example suggesting thetreatment pathway with the highest or a high perceived probability ofsuccess.

According to some embodiments of the present invention, a monitor, or adefibrillator/monitor combination, or other similar device, may beconfigured to provide a graphical tool to configure the monitor tofollow recognized rescue protocols, for example one or more of theprotocols described and/or shown herein. Such a tool may be included onthe monitor or defibrillator device, on a tablet or handheld or othercomputing device, and/or on both, according to embodiments of thepresent invention. Such a tool may be provided in a graphical interface,for example a flowchart. The tool allows the user to configure thepatient monitor to follow a particular rescue protocol, for example byvisually presenting a flow chart for the protocol and allowing the userto customize the protocol. For example, the length of the CPR period maybe configured by the user to customize the treatment protocol. Such atool may also permit the downloading and uploading of customizedtreatment protocols to and/or from a monitoring device, which may alsopermit the same customized protocol settings to be carried on a mobiledevice and/or transferred or uploaded to multiple other devices indifferent locations and/or at different times, according to embodimentsof the present invention.

FIG. 26 illustrates a clinical decision support system 2600, accordingto embodiments of the present invention. System 2600 includes aprocessor 150 which is communicably coupled to a database 152, adecision support module 153, a display 156, and a patient monitor and/ordefibrillator 154, which may itself be communicably coupled to anotherdisplay module 155, according to embodiments of the present invention.Some or all of the elements shown in FIG. 26 may be part of, orimplemented by, one or more computer systems as illustrated in FIG. 27.

FIG. 27 is an example of a computer or computing device system 200 withwhich embodiments of the present invention may be utilized. For example,defibrillator 154 and/or the tablet shown in FIG. 11 may be orincorporate a computer system 200, according to embodiments of thepresent invention. According to the present example, the computer systemincludes a bus 201, at least one processor 202, at least onecommunication port 203, a main memory 208, a removable storage media205, a read only memory 206, and a mass storage 207.

Processor(s) 202 can be any known processor, such as, but not limitedto, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® orAthlon MP® processor(s), or Motorola® lines of processors, or any knownmicroprocessor or processor for a mobile device, such as, but notlimited to, ARM, Intel Pentium Mobile, Intel Core i5 Mobile, AMD A6Series, AMD Phenom II Quad Core Mobile, or like devices. Communicationport(s) 203 can be any of an RS-232 port for use with a modem baseddialup connection, a copper or fiber 10/100/1000 Ethernet port, or aBluetooth® or WiFi interface, for example. Communication port(s) 203 maybe chosen depending on a network such a Local Area Network (LAN), WideArea Network (WAN), or any network to which the computer system 200connects. Main memory 208 can be Random Access Memory (RAM), or anyother dynamic storage device(s) commonly known to one of ordinary skillin the art. Read only memory 206 can be any static storage device(s)such as Programmable Read Only Memory (PROM) chips for storing staticinformation such as instructions for processor 202, for example.

Mass storage 207 can be used to store information and instructions. Forexample, flash memory or other storage media may be used, includingremovable or dedicated memory in a mobile or portable device, accordingto embodiments of the present invention. As another example, hard diskssuch as the Adaptec® family of SCSI drives, an optical disc, an array ofdisks such as RAID (e.g. the Adaptec family of RAID drives), or anyother mass storage devices may be used. Bus 201 communicably couplesprocessor(s) 202 with the other memory, storage and communicationblocks. Bus 201 can be a PCI/PCI-X or SCSI based system bus depending onthe storage devices used, for example. Removable storage media 205 canbe any kind of external hard-drives, floppy drives, flash drives, zipdrives, compact disc-read only memory (CD-ROM), compact disc-re-writable(CD-RW), or digital video disk-read only memory (DVD-ROM), for example.The components described above are meant to exemplify some types ofpossibilities. In no way should the aforementioned examples limit thescope of the invention, as they are only exemplary embodiments ofcomputer system 400 and related components.

As shown in FIG. 26, the decision support module 153 may be a clinicalsupport and/or differential diagnosis and/or treatment protocol asdescribed herein. Based on information about the patient received frommonitor 154, the decision support module 153 determines and/or shows tothe user a set or array of next available options in the decision tree.Alternatively, the decision support module 153 may be configured tocalculate probabilities or other statistics based on decision supporttrees, algorithms, and/or historical data.

Because the display module 155 of the monitor 154 is used forpatient-critical monitoring or treatment functions, and because themonitor 154 must often be small or portable, there may be limited sizeavailability on the display device which display module 155 operates. Assuch, embodiments of the present invention include a separate display156 which is available to the user or to someone other than the user inorder to view information about a particular decision support processbeing implemented by the processor 150 and, optionally, by the patientmonitor 154. When a user decides to implement a decision supportprocess, a selection may be made on the user interface screen operatedby the display module 155, and/or may be made on the user interfaceoperated by display module 156. This then prompts the processor 150 toaccess a clinical decision support process via decision support module153. Decision support module 153 may include logic to guide the userthrough the various nodes and/or branches of a clinical decision supportprocess, for example those shown in FIGS. 5-8B and 12-25. According tosome embodiments of the present invention, the display module 155operates the display screen of a monitor/defibrillator as shown in FIG.11, and the display module 156 operates a tablet computer screen. Such atablet computing device may be communicably coupled to the processor 150(whether such processor is located in the monitor/defibrillator or thetablet computing device) by docking it into a communications dock on themonitor/defibrillator as shown in FIG. 11, and/or may be communicablycoupled to the processor 150 wirelessly. Based on the disclosureprovided herein, one of ordinary skill in the art will recognize thatpatient monitor 154 may include its own processor, and tasks describedas performed by processor 150 may be distributed across one or multipleprocessors and/or physical devices.

FIG. 28 illustrates one example of a decision support tree that may beshown to a user on an auxiliary screen (operated by module 156) during amedical event, to guide the user through a treatment protocol orpre-diagnosis of the patient. The decision support module 153 may benavigated through the various decision points (e.g. “nodes”) either bymanual selection of the next available option or branch, or by completeor partial automatic selection of the next available option or branchbased upon patient data collected during the medical event, for examplephysiological data collected by the patient monitor/defibrillator 154that is connected to the patient, or by a combination of these twoprocesses. A process that is wholly or partially automatic may also beconfigured to prompt a user for confirmation before moving to asubsequent or previous node, according to embodiments of the presentinvention.

Due to the time critical nature of a medical first responder's tasks,such a medical first responder has limited attention resources. In orderto further simplify such a user's interface with a decision supportmodule 153, the processor 150 may be configured to dynamically adjustthe display screen 156 during the medical event. As one example, FIG. 28illustrates a user interface display of a clinical decision supporttree, according to embodiments of the present invention. This decisionsupport tree begins at block 2, and the first decision is between blocks4 or 24. If block 4 is selected, the decision is next between blocks 6and 8. If block 6 is selected, the next decision is between blocks 10and 12. Although one or two possible branches or decisions are shown,one of ordinary skill in the art will appreciate, based on thedisclosure provided herein, that any number of branches or decisionoptions may be provided to extend from a particular node, and that suchbranches could overlap and/or loop back to a previous node, according toembodiments of the present invention. The remaining blocks 14, 16, 18,20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, and 42 may function in asimilar manner.

FIG. 29 illustrates one example of the user interface display of FIG. 28with a portion of the clinical decision support tree resized, accordingto embodiments of the present invention. Once block 4 is selected overblock 24 (manually by the user and/or automatically based on patientdata), the display module 156 resizes the entire “branch” includingblock 24 and its subsequent nodes, and/or resizes each block 24, asshown in FIG. 29, in this case by making them smaller. Alternatively, inanother embodiment, even before the user manually selects block 4, theprocessor 150 instructs the display module 156 to resize the block 24branch as shown in FIG. 29 based on an indication from the decisionsupport module 153, which factors in patient data received (eithermanually or automatically from the monitor 154) to indicate thatchoosing block 4 over block 24 would be more consistent with theparticular clinical decision support process being implemented. Byindicating a size different between block 4 and block 24, the user isprovided a visual indication which, if it coincides with the user'sperceptions and experience, facilitates the navigation through thedecision support process. This also makes such a process easier to usefor those who may not have extensive experience with a particulardecision support protocol.

The resizing may occur by making block 24 smaller, or by making block 4larger, or both. In some cases, only the subsequent sets of blocks ornodes are resized, rather than the rest of the branches or nodesdepending from the immediately subsequent nodes. Each node may berepresented by a shape, and the entire border of the shape may beresized in order to indicate a non-chosen or less-probable node. Asanother alternative, the size of the node may remain the same but thetext inside the node may be resized. As yet another alternative, thesize of the node may remain the same, but the color or transparency ofthe non-chosen or less-probable nodes may be changed, for example“grayed out” for the less important nodes and turned to a bolder coloror flashing color for the more important nodes. A combination of theseand other visual indication features may be employed to assist the userin visually navigating through the decision support process in realtime, during the medical event.

In some cases, the entire decision support tree may be shown on a devicescreen; in other cases, the tree may be too large to show all at once.FIG. 29 also illustrates how a screen border can be recentered or moveddynamically to correspond with movement through the tree. For example,screen border 50 is initially centered (either vertically orhorizontally or both) on block 2, and as soon as block 4 is selected, orbecomes a more likely or recommended selection, the screen border 50shifts along the direction indicated by arrow 52 to new screen borderposition 50′, which is now centered on block 4. FIG. 30 illustrates asimilar resizing feature as it might be displayed after block 6 isselected over block 8.

The decision support module 153 may also be configured to transitionbetween differential diagnosis and treatment protocols; for example, asa likely diagnosis is approached by a clinical support module, the usermay be prompted to select or begin a treatment protocol consistent withone or more likely diagnoses or pre-diagnoses. As another example, oneor more treatment protocol trees may be presented at the end of adifferential diagnosis or clinical decision support tree, in order toguide the user through the recommended treatment protocol once thedecision support module 153 has helped the user identify the conditionthat requires treatment.

The patient monitor/defibrillator device 154 may also be configured forseveral different care modes, and may be configured to enter the mostlikely or most relevant care mode based on the user's navigation of theclinical decision support process, for example on auxiliary display 156,and to change between two or more care modes as appropriate as the usernavigates the clinical decision support tree, according to embodimentsof the present invention.

FIG. 31 illustrates a user interface display with dynamic softkeys,according to embodiments of the present invention. Just as the nodes ona decision support tree display may be dynamically visually adjusted tohelp the user in navigating the process, so too the selection options ona patient monitoring or treatment device 154 may be dynamically adjustedto guide the user through a particular clinical decision supportprocess. FIG. 31 shows a housing of a patient monitor/defibrillator 54,which may include a screen 55 (for example operated by display module155 of FIG. 26), and which may include a number of physical user inputdevices 56, 58, 60, 62, 64, which may be for example buttons. The screen55 may be configured to display a user interface as shown, which mayinclude one or more softkeys 66, 68, 70, 72, 74, with one or more of thesoftkeys 66-74 corresponding to one or more of the buttons 56-64. Basedon the disclosure provided herein, more or fewer buttons and/or softkeysmaybe used, and the positioning of the buttons and/or softkeys may varyacross different units, models, or designs. For example, the buttons mayalternatively or additionally extend vertically across one side of thescreen 55.

The softkeys 66 are part of the display screen that may be dynamicallymodified by the processor 150 and/or the patient monitor 154, such thatthe buttons 56-64 may be used by the user to select different options atdifferent times. This allows the user to navigate through various menuswith a single row of buttons. According to some embodiments of thepresent invention, the device 55 does not include any physical buttons,and instead uses only softkeys on the display screen 55 that arethemselves selectable (e.g. via a touchscreen arrangement). As such, theterm “softkey” is used herein in its broadest sense to refer to anycombination of physical and virtual buttons that may be used by a userto select from one or more options.

Similar to the process described with respect to FIGS. 28-30, thesoftkeys 66 may be dynamically adjusted to assist the user in navigatinga decision support process. Based on the disclosure provided herein, oneof ordinary skill in the art will recognize numerous different menus orclinical decision support processes that may benefit from suchdynamically adjusting softkeys. Just a few particular examples are shownin FIGS. 32 and 33. For example, if a user selected the “acute carediagnose” button or softkey from the user interface display of FIG. 3,the user could be taken to the screen of FIG. 31 with dynamic softkeys66-74. Such softkeys may initially look very similar to those of FIGS. 3and 31; however, according to one embodiment of the present invention,after the user has entered the acute care diagnosis function, and beforethe user has selected the next branch of the process, the patientmonitor/defibrillator observes a cardiac arrhythmia based on thepatient's simultaneously observed ECG waveform. Based on thisphysiological data, the display module 155 emphasizes the CardiacDistress softkey 70 by visually emphasizing it or visuallydistinguishing it over the other simultaneously displayed softkeys, asshown in FIG. 32. For example, the Cardiac Distress softkey 70 may bechanged in color or boldness. The softkey 70 may include a displayedgeometric shape, and such shape may be changed, or its perimeter may bemade bolder or more visually distinct. As another option, the textwithin the softkey 70 may be enlarged or emboldened or italicized inorder to visually distinguish softkey 70 based on the physiologicaldata.

According to some embodiments of the present invention, the userinterface displayed on the screen 55, and/or the screen display of anaccompanying tablet device, includes one or more legends for visuallyindicating to the user why one or more softkeys have been emphasized orhighlighted. For example, such a legend may include text such as“possible cardiac arrhythmia” to explain why the Cardiac Distresssoftkey 70 is emphasized, or “low SpO2” to explain why the RespiratoryDistress softkey 66 is emphasized, or “dispatch: chief complaint=trauma”to explain why the Trauma softkey 72 is emphasized, according toembodiments of the present invention.

As an alternative, or in combination with the color, font, font size,shape, and similar visual distinguishing features, based on thisphysiological data, the display module 155 resizes the Cardiac Distresssoftkey 70 by making it larger, or by making the other softkeys smaller,as shown in FIG. 33. Although FIGS. 32 and 33 illustrate only onesoftkey 70 being emphasized and/or resized based on available patientdata, the display module 155 may further be configured to dynamicallyemphasize and/or resize more than one softkey, in more than one way,according to embodiments of the present invention. For example, if thepatient's blood oxygen content is observed by the monitor 154 as beingbelow a certain threshold, and the patient's ECG waveform is observed bythe monitor 154 as being irregular, both the Cardiac Distress softkey 70and the Respiratory Distress softkey 66 may be visually emphasized orresized with respect to the other softkeys, and may also be visuallyemphasized or resized with respect to each other depending upon therelative significance of each possible diagnosis or treatment protocol.For example, if the decision support module 153 or processor 150 is ableto determine that the cause of the respiratory distress is likelycardiac distress, then the cardiac distress softkey 70 may be thelargest or most emphasized softkey, while the respiratory distresssoftkey 66 may be the next largest or next most emphasized softkey,followed by the remaining softkeys. Once a definitive selection is made,the softkeys 66-74 may be configured to dynamically update to reflectthe next decision/step or set of decisions/steps. The dynamic resizingand/or emphasizing of various softkeys conveys a greater level ofhelpful decision support to the user, without sacrificing the user'sability to select even one of the softkeys that is not enlarged oremphasized, according to embodiments of the present invention.

Although the dynamic adjustment of visual characteristics of softkeyshas been described with respect to observed physiological data about thepatient, such dynamic adjustment may alternatively or additionally beaccomplished using patient charting data or other patient data enteredmanually or automatically. For example, if the patient's chart at thebeginning of the medical event indicates that the patient was involvedin an automobile accident, the Trauma softkey 72 may be configured forinitial enlargement and/or emphasis as soon as the user selects the“acute care diagnose” function from the interface of FIG. 2, accordingto embodiments of the present invention.

FIG. 34 illustrates a code review interface for reviewing user interfacedisplay data corresponding to a medical event, according to embodimentsof the present invention. The code review interface includes a userinterface replicator 455 as well as a visual timeline indicator 300.Throughout a medical event, the user of the patientmonitor/defibrillator 154 takes the display screen 55 of the monitor 154through various steps and user interface modes. It is often helpful,after the medical event has occurred, for the user, as well as someonewho is reviewing or critiquing the performance of the user, to be ableto know what happened during the medical event and when during themedical event such events occurred. Such information is particularlyhelpful in the time leading up to or following a significant patientevent, in order to determine the appropriateness or effectiveness of theparticular treatment applied. To this end, the processor 150 may beconfigured to capture visual representations (e.g. “snapshots” in time)of some or all of the user interface screen 55 and store them for laterreview, for example in database 152, according to embodiments of thepresent invention. Such review may be accomplished in the form of aplayback interface as shown in FIG. 34. Such snapshots of the userinterface 55 may be recorded at least once each second, twice eachsecond, or more times each second, at regular or irregular intervals,according to embodiments of the present invention. In some embodiments,the snapshots may be made frequently enough (e.g. at the data samplerate of 500 snapshots per second) to provide full fidelity playback ofthe event.

The interface replicator 455 and visual timeline indicator 300 may beconfigured to play back the screen user interface appearance at the samerate at which the images were taken or captured, and dynamically movethe position of the timeline indicator 308 along the timeline 300 fromthe beginning time indicator 304 to the ending time indicator 306,according to embodiments of the present invention. A current positionindicator 302 indicates the time, for example in hour:minute:secondformat, at which the particular user interface screen shot shown in theuser interface replicator 455 was taken (or at which such a userinterface displayed during the medical event). As such, a personreviewing the progression of the screen interface 55 sees the screeninterface 55 in the user interface replicator 455 just as it would havebeen seen by the user of the device at the time of the medical event,according to embodiments of the present invention.

The visual timeline indicator 300 may also include visual eventindicators, such as drug administration visual event indicator 310 andpatient defibrillation visual event indicator 312. Other visual eventindicators may include, for example, the occurrence of an alarm, thetime at which a blood pressure measurement or signal was acquired (whichmay be helpful for documenting at the end of a medical event), eventmarkers, clinical decision tree points, the time at which spontaneouscirculation returned (“ROSC”), and/or the time at which a “rearrest”softkey was pressed or at which a renewed or subsequent cardiac arrestcondition was observed.

Visual event indicator 310 indicates the time during the medical event(e.g. on the timeline) at which a drug was administered to the patient.Visual event indicator 312 indicates the time during the medical event(e.g. on the timeline) at which a defibrillation treatment was appliedto the patient, according to embodiments of the present invention. Feweror more of the same or additional visual event indicators may be used inthe visual timeline indicator 300, in order to signal to the reviewerthe times at which significant events of interest occurred during themedical event. This then permits the reviewer to skip directly to theuser interface time intervals of interest, rather than reviewing alluser interface screen shots sequentially, according to embodiments ofthe present invention. As one example of how a user may skip directly toa desired time for playback of the user interface screen, the user mayselect timeline indicator 308 with a cursor or other selection process,and drag it left or right on the timeline before releasing it to resumeplayback at the time corresponding to the new location of the indicator308, according to embodiments of the present invention. According tosome embodiments of the present invention, the user may move theindicator 308 and thus the playback to the time of visual eventindicator 310 (or to a time that is a predetermined interval before thetime of visual event indicator 310) by simply clicking on visual eventindicator 310.

The interface of FIG. 34 may further include a current positionindicator 302, which displays a time corresponding to the position ofthe indicator 308 along the timeline 300 and corresponding to the imagedisplayed in the user interface replicator 455, according to embodimentsof the present invention. While FIG. 34 illustrates a substantiallylinear timeline, other non-linear timeline indicators may be used. Thecode review interface of FIG. 34 may also be particular helpful inreviewing the recorded screen images for dynamic softkey adjustments, asdescribed with respect to FIGS. 32 and 33. For example, if a user failedto select a particular softkey that was later determined to have beenthe preferred course of action, the code reviewer could set theindicator 308 to the time that such softkey was displayed to see whetherthe particular softkey was resized or emphasized in order to indicatethat it was the preferred course of action. Reviewers using theinterface of FIG. 34 are also able to see what exactly was on the user'sscreen when certain actions were undertaken, for example what the userlooked at just prior to the drug administration event 310, according toembodiments of the present invention. According to some embodiments ofthe present invention, the interface of FIG. 34 operates in a mannersimilar to that of digital video recorder playback.

Screen controls consistent with user interfaces that play back moviesmay be included in the interface of FIG. 34. For example, the interfacemay include a media navigation interface including media navigation bar314, volume selection bar 314, and/or playback speed selection bar 316.The media navigation bar 314 may include screen controls similar tothose used with playback of movies, to control the content of the userinterface replicator. For example, the media navigation bar 314 mayinclude a play button 322, a stop button 324, a pause button 326, arewind button 320, and a fast forward button 328. A skip back button 314and skip forward button 330 may also be included, for example to skipbetween medical events, chapters, and/or visual event indicators,according to embodiments of the present invention. As used herein,“button” is used to refer to either or both of a physical button or avirtual/screen selection interface option. By clicking on or otherwiseselecting one of the 2×, 4×, 8×, or 16× portions of the playback speedselection bar 316, the speed at which the medical vent is played on theuser interface replicator 455 may be adjusted. The playback speedselection bar 316 may also be configured to visually indicate which ofthe playback speed selections is currently active. Other or additionalspeed selections may be provided. Clicking on or otherwise selectingvolume selection bar 314 permits adjustment of any audio playback volume(e.g. when audio data from the medical event is also played backsimultaneously or instead of the visual data).

According to some embodiments of the present invention, the on-screencursor 334 (or other selection mechanism) may take the form of a handwith a pointed finger. When the finger is placed over, on, or near thetimeline, a display preview pop-up window 332 opens, for exampleattached or in the vicinity of the finger or cursor 334. The displaypreview window 332 may show, for example, a physiologic waveform alongwith static measurements and time and events in sufficient detail forthe user to determine whether to select that particular timelinelocation for current playback, according to embodiments of the presentinvention. The display preview window 332 includes the physiologicwaveform and measurements/events portion 336, as well as a timeindicator portion 338 indicating where, along the visual timelineindicator 300, the cursor 334 has been placed, according to embodimentsof the present invention. According to some embodiments of the presentinvention, selecting and “holding” the selection on the timelineindicator 308 and scrolling forward and backward along the timeline 300causes a similar display preview window 332 to pop up at or near theslider 308.

According to some embodiments of the present invention, the user canplay back the clinical decision support tree for reviewing the medicalevent. For example, a tablet screen, or a screen controlled by displaymodule 156, or alternatively an interface similar to that of FIG. 34,could be configured to indicate a timeline and display the user'sprogression through a clinical decision support tree by highlightingeach node through which the process was taken, and the time at whichsuch node selection was made. According to some embodiments of thepresent invention, a representation of the clinical decision supporttree is itself used as a visual timeline indicator, permitting a user toselect a node in order to see, in the user interface replicator 455,what the defibrillator/monitor 154 screen 55 looked like at the time ortimes when the user was at the selected step in the decision supportprocess. According to some embodiments, the display module 156 andprocessor 150 may communicably coupled bi-directionally with thedefibrillator/monitor 154, and the defibrillator/monitor 154 screen 55itself may be used as (for example instead of) the user interfacereplicator 455. In addition to being able to select a particular node inthe decision support tree to view the monitor display at that selectedstep, the tablet computer screen or other display device operated bydisplay module 156 may be configured to show a user-selectable list ofevent markers which, when selected by the user, replicates the monitor's154 display at the time of the marked event, either using display module155 or user interface replicator 455, according to embodiments of thepresent invention. For example, the following list of event markerscould be displayed on a tablet computing device communicably coupled tothe defibrillator/monitor 154:

03:05:00 SBP 110/80, HR 99, SpO₂ 95%

03:08:00 alarm: SpO₂ 88%

03:08:30 event: O₂ delivery

03:10:00 SBP 105/82, HR 110, SpO₂ 92%

03:11:01 event: ACLS arrive

Although FIG. 34 depicts a user interface replicator 455, otherreplicators may be used to display or play back other observedparameters that occurred over the course of a medical event; forexample, graphs, trends, and/or charts representing patient informationor physiological status. Such an ability to quickly and efficientlyreview patient data for a medical event or portions thereof may behelpful not only for a subsequent reviewer, but may also be helpful forthe user during the medical event, and/or for a subsequent user duringthe medical event, for example when a patient is transferred from aBasic Life Support crew to an Advanced Life Support crew. The interfaceof FIG. 34, or a similar interface, may permit review of the patient'scare report, ECG or 12-lead waveforms, cardiopulmonary resuscitationquality, and other patient care information or data. Event markers maybe used as described above. As another example, an event marker may beused to indicate that the patient was administered a bronchodilatormedication, and the code review interface may be used to look at thepatient's respiratory status before and after the application of thebronchodilator. This permits the same user, or a subsequent user for thesame patient, or a subsequent reviewer, to observe how effective thebronchodilator dosage was, and perhaps to factor such information into adecision to again administer the same or another treatment. As anotherexample, the interface of FIG. 34 or a similar interface may be used toreview how the patient's carbon dioxide waveform changes upon patienttreatment. “Snapshots” may be recorded and played back through a similarinterface for other patient data, for example the data from aventilation monitoring device (e.g. minute ventilation).

According to some embodiments of the present invention, alarm thresholdsmay be dynamically adjusted based on patient physiological data and/orcharting data. In addition, frequency-automated measurements, forexample blood pressure, may be adjusted based on patient physiologicaldata and/or charting data, for example by changing the frequency of suchmeasurements. For example, when a traumatic brain injury is suspected ordiagnosed based on the patient physiological data, charting data, and/orvia following a clinical decision support process, the monitor 154 maybe configured to automatically obtain vital signs (e.g. blood pressure,SpO₂, heart rate, and respiratory rate) every five minutes. For other,less critical conditions, these vital signs may only need to be takentwice during the entire patient event. As another example, automaticblood pressure measurements may be disabled when treating a cardiacpatient, and then re-enabled once the patient achieves return ofspontaneous circulation.

As another example illustrating how alarm thresholds may be dynamicallyadjusted based in a traumatic brain injury medical event, a systolicblood pressure (“SBP”) alarm may be configured on the monitor 154 toalert the user with an alarm if an adult's SBP is less than 90 mmHg,with a ventilation rate target of 10 breaths per minute, and/or the endtidal carbon dioxide is less than 35 mm Hg. These targets may need to beadjusted based on a patient's age; for example, for a three-year old, asystolic blood pressure alarm may be set to activate with an SBP of lessthan 76 mmHg and/or a ventilation rate target of twenty breaths perminute. For a one-year old, a systolic blood pressure alarm may be setto activate with an SBP of less than 72 mm Hg, and/or a ventilation ratetarget of twenty-five breaths per minute. According to embodiments ofthe present invention, the processor 150 is configured to automaticallyadjust the thresholds based on the patient's age, in a traumatic braininjury situation, based on user input, rather than requiring the user tomanually reconfigure the alarm thresholds based on age. For example, theprocessor 150 may obtain the patient's age from database 152, and/orfrom a patient charting system to which it is communicably coupled, anduse the patient's age to automatically reconfigure the alarm thresholdsupon an indication, either via a softkey selection or from the decisionsupport module 153, that a traumatic brain injury situation applies.Alternatively, the clinical decision support tree for traumatic braininjury may, at the appropriate node in the process, request the user toselect from various age groupings, and use the user's selection from thedecision support tree to automatically adjust the alarm thresholds. Theprocessor 150 may also be configured to silence all alarms upon adetermination that the patient has entered cardiac arrest, and thenre-enable all alarms upon a determination that the patient has achieveda return of spontaneous circulation. According to some embodiments ofthe present invention, the processor 150 may be configured to, after acardiac arrest event for an adult, reset the alarm thresholds to endtidal carbon dioxide <30 mm Hg (possibly lower for a traumatic braininjury situation) or heart rate <40 beats per minute. While alarm andother thresholds are discussed as being adjustable in traumatic braininjury medical events, alarms and other thresholds may also bedynamically adjusted for other patient events or conditions, accordingto embodiments of the present invention.

According to embodiments of the present invention, system 2600 is usedto assist clinicians with delivering medications of the appropriatedose. Medication errors can cause significant problems, particularly forthe treatment of pediatric patients and when drugs are substituted.According to some embodiments of the present invention, the decisionsupport module 153 displays assistance for physicians to comply with aprotocol, for example a protocol related to drug delivery. For example,a medical director may provide drug options for treatment of aparticular condition. The dosing of the drug would be determined basedon patient age, body weight, Broselow measurement, and/or medicalcomplaint. At any time, the medical director may change the drug optionsand dosing based on factors such as the availability of the drug. Aphysician might even change the recommendations in real-time or inclinical time if remotely monitoring the treatment. The system mayinclude protections and/or safeguards to ensure that the information iscorrectly entered into the database 152 about the drug and/or thepatient, in order to permit the decision support module 153 toaccurately guide the caregiver in dosing according to the current drugdelivery protocol, according to embodiments of the present invention.

As shown in FIG. 35, part of a process, for example a clinical decisionsupport tree, has a decision process that flows through arrow 401 andinto decision point 400, system 2600 may assist the decision supportmodule 153 in determining whether to select, suggest, and/or recommendnode 402 or node 404, according to embodiments of the present invention.After node 402 is selected, the process may continue to the next nodevia arrow 403. After node 404 is selected, the process may continue tothe next node via arrow 405, according to embodiments of the presentinvention. As shown in FIG. 35, a drug delivery portion of a clinicaldecision support tree may, at node 400, have the decision support module153 determine a correct dosing for the particular patient based on uponobserved and/or input patient characteristics (block 406), and/or maydetermine or suggest or recommend one of two or more doses, for exampledose A (block 402) or dose B (block 404), according to embodiments ofthe present invention. The observed and/or input patient characteristics(block 406) that might suggest different dosing include age, weight,allergies, and/or other conditions, according to embodiments of thepresent invention.

FIG. 36 illustrates a user interface, for example a user interface for apatient monitor/defibrillator 154 or other device. The user interface ofFIG. 36 includes display portions which indicate trending informationfor various values. For example, the interface illustrates trending datafor systolic blood pressure (referenced as 3600), end tidal carbondioxide (EtCO2), and blood oxygen saturation (SpO2). Trending data maybe displayed as a running record of previous readings. The oldestreadings may appear on the left, and the newest readings may appear onthe right, and the newest reading may be inserted on the right sidewhile displacing the oldest reading on the left side, according toembodiments of the present invention. Alternatively, the oldest readingsmay appear on the right, and the newest readings may appear on the left,and the newest reading may be inserted on the left side while displacingthe oldest reading on the right side. Other options for visuallyindicating the trend data for a given signal may be employed.

Conventional trending data displays for medical devices, for example apatient monitor/defibrillator 154, help a clinician assess patienthistory and condition, but they often fail to convey information abouthow the trending values compare with acceptable values or ranges ofvalues, or user-defined values or ranges of values. According to someembodiments of the present invention, the scaling of the trendingreadouts, and/or the frequency of the values displayed for the trendingvalues, and/or a color in which the trending values are displayed, iscustomized according to the particular patient and/or the patient'scondition. This may be done by the decision support module 153. Forexample, if as part of a decision support process the decision supportmodule 153 receives information indicating a patient's age, then theprocessor may be configured to configure the color in which each bar ofthe blood pressure trending graph 3600 is displayed.

The three bars on the left 3602 may be displayed as green to indicatethat the patient's blood pressure at the times corresponding to thoseparticular blood pressure measurements was within acceptable limits forthe patient's age. The middle five bars 3604 may be yellow to indicatethat the patient's blood pressure at the times corresponding to thoseparticular blood pressure measurements was below acceptable limits, butnot yet at a critical level. The right three bars 3606 may be red toindicate that the patient's blood pressure at the times corresponding tothose particular blood pressure measurements was far below acceptableranges, and was therefore at a critical level. In embodiments in whichthe newest trending values appear on the right side, the trend graph3600 for patient systolic blood pressure indicates that the patient'sblood pressure is worsening over time by becoming lower. Of course,other colors may be used, and additional colors and/or ranges may beemployed. These ranges may be automatically adjusted by the decisionsupport module 154 based on various factors, for example the patient'sage, or other conditions. For example, all of the bars 3602, 3604, and3606 can be displayed as green for a normal adult patient, while thesame absolute readings may be colored as shown in FIG. 35 for a youngeror adolescent patient. The coloring, target ranges, or other visualindication of the trending data may also be adjusted by the decisionsupport module 153 during the patient monitoring event, based on dataobserved by the patient monitoring device 154.

According to some embodiments of the present invention, the clinicianmanually adjusts the target values of signals, which may be beneficialif the patient is “crashing,” for example. Instead of a screen full ofred target values, the clinician could select ranges which correspond toconditions with a more realistic chance of being achieved, according toembodiments of the present invention.

According to some embodiments of the present invention, if a patient hascerebral herniation or impending cerebral herniation, the ETCO2 and/orventilation rate targets may be changed in order to hyperventilate suchpatients so as to reduce intracranial pressure. These ranges or targetsmay be adjusted automatically if, in the course of a decision supportprocess, the decision support module 153 detects, either automatically,or via manual or clinical or other inputs, that the patient has or isabout to experience cerebral herniation.

According to some embodiments of the present invention, if the decisionsupport module 153 detects that the ETCO2 is below a certain threshold,the target ventilation rate will be adjusted to lower the ventilationrate. If the decision support module 153 detects that the ETCO2 is abovea certain threshold, the target ventilation rate will be adjusted toincrease the ventilation rate, according to embodiments of the presentinvention. Such adjusted ventilation rates may include an upper and/orlower limit to prevent other undesired results, because high or lowETCO2 readings may be caused by factors other than ventilation rate(e.g. a super low ETCO2 may be caused by perfusion).

Various modifications and additions can be made to the exemplaryembodiments discussed without departing from the scope of the presentinvention. For example, while the embodiments described above refer toparticular features, the scope of this invention also includesembodiments having different combinations of features and embodimentsthat do not include all of the described features. Accordingly, thescope of the present invention is intended to embrace all suchalternatives, modifications, and variations as fall within the scope ofthe claims, together with all equivalents thereof.

1. (canceled)
 2. A method for code review of a medical event, the methodcomprising: displaying, on a first device screen, a user interfaceduring the medical event; recording data presented by the user interfacefrom the medical event, the presented data of the user interfaceassociated with a time during the medical event, wherein the data isrecorded at least once every second; displaying, on a second devicescreen, a visual timeline indicator and a user interface replicator, theuser interface replicator displaying visual representations of the datapresented by the user interface and the visual timeline indicatorrepresenting a time associated with each of the visual representations,wherein the visual timeline indicator and the user interface replicatorpermit sequential playback and review of the visual representations ofthe data presented by the user interface from the medical event, andwherein the visual timeline indicator accepts user input to move thesequential playback to a different time associated with the medicalevent.
 3. The method of claim 2, wherein recording data presented by theuser interface comprises recording images of the user interface from themedical event.
 4. The method of claim 3, wherein the visualrepresentations of the data presented by the user interface comprise therecorded images of the user interface from the medical event.
 5. Themethod of claim 2, wherein the visual timeline indicator includes atimeline including a beginning time of the medical event and an end timeof the medical event, the method further comprising indicating on thetimeline the time associated with the data presented by the userinterface shown in the user interface replicator.
 6. The method of claim5, wherein the indicating on the timeline comprises using an indicatoron the timeline to indicate the time associated with the data presentedby the user interface shown in the user interface replicator.
 7. Themethod of claim 6, further comprising advancing the indicator along thetimeline in a direction from the beginning time toward the end timeduring sequential playback of the visual representations of the datapresented by the user interface.
 8. The method of claim 7, wherein thevisual timeline indicator accepts user input by permitting scrolling ofthe indicator to a different position along the timeline.
 9. The methodof claim 5, wherein the visual timeline indicator displays the timeassociated with each of the images in an hour-minute-second format. 10.The method of claim 5, wherein the visual timeline indicator includesone or more event markers marking occurrence of clinically-relevantsub-events during the medical event.
 11. The method of claim 10, whereinthe one or more event markers include a drug event marker indicating atime at which a drug was administered to a patient during the medicalevent.
 12. The method of claim 10, wherein the one or more event markersinclude a defibrillation event marker indicating a time at which adefibrillation shock was applied to a patient during the medical event.13. The method of claim 10, wherein the one or more event markersinclude an ROSC event marker indicating a time at which a patientreturned to spontaneous circulation.
 14. The method of claim 10, whereinthe one or more event markers include a rearrest event marker indicatinga time at which a patient returned to cardiac arrest.
 15. The method ofclaim 10, wherein the one or more event markers include an alarm eventmarker indicating a time at which an alarm was activated.
 16. The methodof claim 2, further comprising displaying a cursor on the second devicescreen and, when the cursor is hovered over or near a time representedby the visual timeline indicator, displaying on the second screen at ornear the cursor the image of the user interface associated with thetime.
 17. The method of claim 16, further comprising, when the cursor ishovered over or near the time, displaying at or near the cursor atextual representation of the time.
 18. The method of claim 2, whereinthe second device screen is integrated with at least one of a heads updisplay, a wearable device, and a hands-free device.
 19. The method ofclaim 2 wherein the second device screen is projected onto a user'sglasses or face shield.
 20. The method of claim 2, wherein the userinterface comprises two or more softkeys each representing a possibleuser selection.
 21. The method of claim 20, further comprisingcollecting physiological data from a patient with a medical device. 22.The method of claim 21, further comprising identifying, based on thephysiological data, a type of the medical event.
 23. The method of claim22, further comprising determining, in response to the type of themedical event, which one of the two or more softkeys represents thepossible user selection that most closely conforms to a treatment ordiagnosis protocol, and based on the determination, visuallydistinguishing the one of the two or more softkeys from the others ofthe two or more softkeys on the user interface.
 24. The method of claim23, wherein visually distinguishing the one of the two or more softkeyscomprises at least one of making the one of the two or more softkeyslarger than the others of the two or more softkeys, changing a positionof the one of the two or more softkeys on the user interface, changing acolor of the one of the two or more softkeys on the user interface,changing a border of the one of the two or more softkeys on the userinterface, making the one of the two or more softkeys dynamically flashon the user interface, and displaying on the screen a legend describingwhy the one of the two or more softkeys has been visually distinguished.25. The method of claim 24, wherein the one of the two or more softkeysis a cardiac distress softkey, and wherein the legend textuallyindicates a possible cardiac arrhythmia.